Digital content distribution system

ABSTRACT

The content distribution system according to the present invention is comprised of: a server device and a terminal device, the server device providing the terminal device with a license for using a content based on transaction processes, each including receiving of a request message, sending of a response message, and receiving of a commit message for finalizing completion of a transaction, and the terminal device controlling use of the content based on the license obtained from the server device, wherein the terminal device includes: a holding unit that holds a 1-bit transaction identification flag indicating whether a current transaction process is in progress or completed; and a sending unit that sends the transaction identification bit instead of an omitted commit message when sending a second or later request message, without sending a commit message in each transaction process except for a last transaction process in successive transaction processes, and the server device includes: a receiving unit that receives the transaction identification flag that is sent together with the second or later request message in the successive transaction processes; and a judgment unit that judges whether or not completion of one transaction should be finalized based on the received transaction identification flag.

TECHNICAL FIELD

The present invention relates to a system in which a digital contentsuch as video and music, and a license permitting use of the digitalcontent are distributed from a server device over a network and in whicha user uses the digital content by a terminal device. More particularly,the present invention relates to a system and devices that prevent theunauthorized duplication and tampering of the license in a communicationbetween the server device and the terminal device as well as preventingthe loss and double-distribution of the license even in the event of theoccurrence of a communication disconnection.

BACKGROUND ART

In recent years, a system referred to as a content distribution systemhas come into practical use. A content distribution system is a systemin which a digital content such as music, video, and game (such adigital content is hereinafter described as a content) is distributedfrom a server device to a terminal device through a communication overthe Internet or the like or through a digital broadcasting or the like,and in which it is possible to use the content by the terminal device. Ageneral content distribution system uses copyright protection technologyin order to protect the copyright of a content and to preventunauthorized use of the content by a malicious user or the like. Morespecifically, the copyright protection technology is a technology forsecurely controlling the user's use of a content through use ofcryptography or the like, such as the reproduction of the content andthe copying of the content onto a storage medium.

For example, as an example content distribution system, Patent Document1 describes a system in which a terminal device, after receiving anencrypted content, a usage condition, and a content decryption key froma server device and performing tampering detection, verifies theconformity to the usage condition, and decrypts and outputs the contentonly when all of the verification requirements are satisfied.

As described above, in the conventional content distribution system,since a license (which is a generic name for the usage condition andcontent decryption key, and is also referred to as a usage right) isdistributed from the server device to the terminal device generallythrough a public network such as the Internet, it is necessary toprevent the tapping and tampering of the license. In other words, it isnecessary to prevent the tampering of the usage condition and theleakage of the content key. Furthermore, the server device is requiredto authenticate the terminal device to which the license is to bedistributed. In other words, it is also necessary to prevent the serverdevice from distributing the license to an unintended terminal device.Protocols intended for the prevention of tapping and tampering and forthe authentication of the party at the other end are called SecureAuthenticated Channel (SAC) protocols, of which Secure Socket Layer(SSL) is well known, for example (Non-patent Document 1).

Meanwhile, in the case where a communication disconnection occurs duringthe license distribution due to the breakdown of the communicationdevice or the communication line, power failure, or others, there is apossibility that such license is lost. This causes a loss to the usersuch as that the user cannot reproduce the content s/he has purchased.For example, Patent Document 2 and Patent Document 3 describe a protocolfor preventing the loss of communication data attributable to acommunication disconnection by re-sending the data.

(Patent Document 1): Japanese Patent No. 3276021

(Patent Document 2): Japanese Laid-Open Patent application No.2002-251524

(Patent Document 3): Japanese Laid-Open Patent application No.2003-16041

(Non-patent Document 1): A. Frier, P. Kariton, and P. Kocher, “The SSL3.0 Protocol”, [online], NetScape Communication Corp., Nov. 18, 1996,[searched on Jan. 17, 2003], Internet <URL:http://wp.netscape.com/eng/ssl3/draft302.txt.>

However, in order to expand the scope of application, a SAC protocol anda communication disconnection countermeasure protocol place theiremphasis on the versatility and each of them are proposed individually.For this reason, in order to achieve all the functions using both of theabove protocols, that is, the prevention of license tapping andtampering, the authentication of the party at the other end, andcountermeasures for communication disconnection, sendings and receivingsare required to be performed for the number of times required for theboth protocols.

Furthermore, in the case where transactions such as obtainment andreturning of a license need to be carried out in a successive manner andthe SAC protocol and the communication disconnection countermeasureprotocol are simply repeated on a transaction basis, the number ofsendings and receivings increases by a multiple of the number ofsendings and receivings required to be performed per transaction. Forexample, letting that the number of sendings and receivings required pertransaction is 4, sending and receiving needs to be performed for 4ntimes to process “n” transactions.

This causes a problem that there occurs a delay in a communication untilthe terminal device completes transaction processes and thus the userhas to wait until such user receives a response after making a request.

DISCLOSURE OF INVENTION

The present invention aims at solving the conventional problem asdescribed above, and it is an object of the present invention to providea system and devices with which it is possible to (1) achieve all thefunctions, that is, the prevention of license tapping and tampering, theauthentication of the party at the other end, and countermeasures forcommunication disconnection, (2) reduce the number of times sendings andreceivings are carried out between a server device and a terminal devicein the case where plural transaction processes are performed, and (3)realize a protocol that requires the server device and the terminaldevice to manage and hold a small amount of information to achieve theabove functions. Through the above, the present invention aims atproviding a content distribution system that is capable of reducing thetime the user has to wait until such user receives a response aftermaking a request.

The terminal device that achieves the above object is a terminal devicethat obtains, from a server device, a license for using a content basedon transaction processes and controls use of the content based on thelicense, each of the transaction processes including sending of arequest message, receiving of a response message, and sending of acommit message for finalizing completion of one transaction, theterminal device including: a holding unit that holds a 1-bit transactionidentification flag indicating whether a current transaction process isin progress or completed; and a sending unit that sends the transactionidentification bit instead of a commit message when sending a second orlater request message, without sending a commit message in eachtransaction process except for a last transaction process in successivetransaction processes.

Furthermore, the server device that achieves the above object is aserver device that provides a terminal device with a license for using acontent based on transaction processes, each including receiving of arequest message, sending of a response message, and receiving of acommit message for finalizing completion of one transaction, the serverdevice including: a receiving unit that receives a 1-bit transactionidentification flag that is sent, instead of the commit message,together with a second or later request message in successivetransaction processes, the transaction identification flag indicatingwhether a transaction process is in progress or completed in theterminal device; and a judgment unit that judges whether or notcompletion of one transaction should be finalized based on the receivedtransaction identification flag.

With the above structure, in the case where plural transaction processesare performed in a content distribution system that includes theterminal device and the server device, a transaction identification flagis sent instead of a commit message, together with a request message. Inother words, with the above structure, a commit message and a requestmessage that are conventionally sent separately in two successivetransaction processes are sent by being multiplexed as a single message.As described above, since a commit message is not sent, it is possibleto reduce the number of times message sendings and receivings arecarried out between the server device and the terminal device.Furthermore, a small amount of information, a 1-bit transactionidentification flag, allows the server device and the terminal device toachieve both the reduction in the number of message sendings andreceivings and countermeasures for communication disconnection.Accordingly, it is possible to reduce the time the user has to waituntil such user receives a response after making a request.

Here, the terminal device may include: a response receiving unit thatreceives each response message sent from the server device in thetransaction processes; and an update unit that updates the transactionidentification flag held by the holding unit according to each receptionresult of the response receiving unit. Furthermore, the update unit mayset a same value as a value of a transaction identification flag held bythe server device as an initial value of the transaction identificationflag held by the holding unit, and may invert a value of the transactionidentification flag held by the holding unit when a response message isreceived by the response receiving unit.

Here, in the server device, a value of the transaction identificationflag may be inverted every time a transaction is processed by theterminal device, and the server device may further include a holdingunit that holds a first flag that is a copy of the transactionidentification flag that is sent together with a preceding requestmessage in the transaction processes, wherein the judgment unit mayjudge that completion of a preceding transaction should be finalized inthe case where the transaction identification flag in the currenttransaction process and the first flag held by the holding unit do notmatch, the transaction identification flag being received by thereceiving unit.

With the above structure, it is possible for the judgment unit in theserver device to judge whether the preceding transaction process hascompleted or not in the terminal device by comparing the first flag thatis a copy of the preceding transaction identification flag and thecurrent transaction identification flag received.

Here, in the terminal device, the initial value of the transactionidentification flag may be included in a first response message sentfrom the server device in the transaction processes, and the update unitmay set the transaction identification flag held by the holding unit tothe initial value when the response receiving unit receives the firstresponse message, and may invert the value of the transactionidentification flag held by the holding unit when a response message isnormally received by the response receiving unit.

Here, the server device may include a response sending unit that sends,to the terminal device, an initial value of the first flag as an initialvalue of the transaction identification flag, together with a firstresponse message in the transaction processes.

With the above structure, the judgment unit in the server device judgesthat the transaction process has not completed in the case where thefirst flag and the current transaction identification flag receivedmatch since there is no change in the state of the transaction processin the terminal device, whereas it judges that the transaction processhas completed in the case where they do not match since there is achange in the state of the transaction process in the terminal device.As described above, it is possible for the server device to easily judgethe state of a transaction process (whether it has completed or not) inthe terminal device based on a transaction identification flag, withoutreceiving any commit messages.

Here, the request sending unit in the terminal device may send again thetransaction identification bit that is not inverted, together with arequest message for the current transaction process, in the case where aresponse message is not normally received by the response receivingunit.

Here, the response sending unit may send again the response message forthe preceding transaction process in the case where the judgment unitjudges that the completion of the preceding transaction should not befinalized.

Here, the terminal device may perform processing for mutualauthentication with the server device immediately before a firsttransaction process in the transaction processes, and may furtherinclude: an authentication unit that: provides the sending unit withfirst authentication information as an authentication request, the firstauthentication information being used by the server device toauthenticate the terminal device; verifies second authenticationinformation that is received by the response receiving unit as aresponse to the first authentication information, the secondauthentication information being used by the terminal device toauthenticate the server device; and provides the sending unit with afinalization message for finalizing the mutual authentication accordingto a result of the verification, wherein the sending unit may send thefinalization message together with a request message for the firsttransaction process. Furthermore, the server device may performprocessing for mutual authentication with the terminal deviceimmediately before a first transaction process in the transactionprocesses, and may further include: an authentication unit that:verifies first authentication information that is received by thereceiving unit as an authentication request, the first authenticationinformation being used by the server device to authenticate the terminaldevice; and provides second authentication information that is used bythe terminal device to authenticate the server device in the case wherethe first authentication information is verified as valid, wherein therequest receiving unit may receive a finalization message for finalizingthe mutual authentication together with the first request message.

With the above structure, since the server device and the terminaldevice perform plural transaction processes via a secure communicationpath that is established through the above authentication, it ispossible to prevent spoofing which is masquerade as an authorizedterminal device, message tampering, and message tapping, in addition tobeing able to achieve the above-described countermeasures forcommunication disconnection.

Here, in the terminal device, the transaction processes may be performedon a session that is same as a session on which the mutualauthentication has been performed.

With the above structure, in the case where n transaction processes areperformed, it is possible to reduce the number of sendings andreceivings to n+2 times from some 4n times which is the number ofsendings and receivings having been required to be carried outconventionally.

As described above, according to the terminal device and the serverdevice of the present invention, it is possible to achieve all thefunctions, that is, the prevention of license tapping and tampering, theauthentication of the party at the other end, and countermeasures forcommunication disconnection as well as to reduce the number of timessendings and receivings is carried out between the server device and theterminal device in the case where plural transaction processes areperformed. Furthermore, it is possible to realize a protocol thatrequires the server device and the terminal device to manage and hold asmall amount of information to achieve the above functions. Accordingly,it becomes possible to reduce the time the user has to wait until suchuser receives a response after making a request.

BRIEF DESCRIPTION OF DRAWING

FIG. 1 is a block diagram showing a structure of a content distributionsystem according to an embodiment of the present invention.

FIG. 2 is a block diagram showing a detailed structure of a securitymanagement/communication unit of a content distribution device accordingto an embodiment of the present invention.

FIG. 3 is a block diagram showing a detailed structure of a securitymanagement/communication unit of a user terminal according to anembodiment of the present invention.

FIG. 4 is a flowchart that describes processing related to the purchaseof a content to be performed in the content distribution systemaccording to an embodiment of the present invention.

FIG. 5 is a diagram that schematically shows an example ofcontent-related information stored in a content right database 19.

FIG. 6 is a diagram that schematically shows an example of userinformation stored in a user database 18.

FIG. 7 is a diagram that schematically shows an example of informationabout rights owned by users stored in a user-owned right database 20.

FIG. 8 is a diagram that schematically shows an example of contentinformation stored in a content database 21.

FIG. 9 is a flowchart that describes processing related to the use of acontent to be performed in the content distribution system according toan embodiment of the present invention.

FIG. 10A is a diagram that illustrates four types of communicationphases in which plural transaction processes are performed between thecontent distribution device 1 and the user terminal 3.

FIG. 10B is a diagram that illustrates the transition of the transactionidentification bit in the case where plural transaction processes arenormally performed between the content distribution device 1 and theuser terminal 3.

FIG. 10C is a diagram that illustrates the transition of the transactionidentification bit in the case where a response message fails to havebeen delivered from the content distribution device 1 to the userterminal 3.

FIG. 10D is a diagram that illustrates the transition of the transactionidentification bit in the case where a request message fails to havebeen delivered from the user terminal 3 to the content distributiondevice 1.

FIG. 11 is a flowchart that describes processing to be performed by theuser terminal 3 and the content distribution device 1 in an initialphase in content use processing performed in the content distributionsystem according to an embodiment of the present invention.

FIG. 12 is a flowchart that describes processing to be performed by theuser terminal 3 before the start of a first command communication phaseafter the initial phase that is performed between the user terminal 3and the content distribution device 1, in the content use processingperformed in the content distribution system according to an embodimentof the present invention.

FIG. 13 is a flowchart that describes processing to be performed by theuser terminal 3 and the content distribution device 1 in a first commandcommunication phase in the content use processing performed in thecontent distribution system according to an embodiment of the presentinvention.

FIG. 14 is a flowchart that describes processing to be performed by theuser terminal 3 and the content distribution device 1 in a commandcommunication phase in the content use processing performed in thecontent distribution system according to an embodiment of the presentinvention.

FIG. 15 is a flowchart that describes processing to be performed by theuser terminal 3 and the content distribution device 1 in a commit phasein the content use processing performed in the content distributionsystem according to an embodiment of the present invention.

BEST MODE FOR CARRYING OUT THE INVENTION First Embodiment

FIG. 1 is a block diagram showing a structure of a content distributionsystem according to an embodiment of the present invention. In FIG. 1,the content distribution system according to an embodiment of thepresent invention has a structure in which a content distribution device1 being a service provider and a user terminal 3 being a user areconnected via a transmission line such as a network.

The content distribution device 1 is comprised of a content purchaseprocessing unit 11, a user registration unit 12, a user rightregistration unit 13, a user right generation unit 14, a contentencryption unit 15, a content management unit 16, a securitymanagement/communication unit 17, a user database 18, a content rightdatabase 19, a user-owned right database 20, and a content database 21.Meanwhile, the user terminal 3 is comprised of a user instructionprocessing unit 31, a terminal information storage unit 32, a contentstorage unit 33, a usage right management unit 34, a usage rightdatabase 35, a security management/communication unit 36, and an outputunit 37.

First, a description is given below of an overview of the contentdistribution device 1 and the user terminal 3 that make up the abovecontent distribution system.

In the content distribution device 1, when content purchase processingis performed, the content purchase processing unit 11 sends, to the userterminal 3, information stored in the content right database 19 such asdetails, a usage condition, and the fee of each content, so as topresent such information to the user. Furthermore, when the userpurchases a content, the content purchase processing unit 11 obtainsuser information (user ID, terminal ID, user name, telephone number, orthe like) from the user terminal 3, and performs necessary chargingprocessing. In the content right database 19, one or more informationregarding content use is stored for each content (moving images such asmovie and TV broadcasting, still images such as book and printed matter,audio and music such as radio broadcasting and recitation, game, and thelike).

The user registration unit 12 stores and registers, into the userdatabase 18, the user information obtained by the content purchaseprocessing unit 11. Information about users who have purchased contentsare cumulatively stored in the user database 18.

The user right registration unit 13 stores and registers, into theuser-owned right database 20, the information about the contentpurchased by the user as a right owned by the user, the informationbeing provided from the content purchase processing unit 11 via the userregistration unit 12. The usage rights of contents purchased by usersare stored in the user-owned right database 20.

The user right generation unit 14 generates a usage right (a use ruleand a content decryption key) to be sent to the user terminal 3according to a content use request received from the user terminal 3.

The content encryption unit 15 encrypts the content to be sent to theuser terminal 3, and registers the encrypted content into the contentdatabase 21.

The content management unit 16 retrieves, from the content database 21,the encrypted content to be sent to the user terminal 3, and passes itto the security management/communication unit 17.

The security management/communication unit 17 performs: authenticationof the user terminal 3; secure communications (communications forpreventing tapping and tampering and for authenticating the party at theother end) between the content distribution device 1 and the userterminal 3; and countermeasures for communication disconnection. Detailsabout the structure of the security management/communication unit 17 andthe communication protocol are given later.

The user instruction processing unit 31 in the user terminal 3 processesinstructions (instructions including a content purchase request and acontent use request) inputted by the user.

The above-described user information (user ID, terminal ID, user name,telephone number or the like) is stored in the terminal informationstorage unit 32.

The encrypted content obtained through purchase is stored in the contentstorage unit 33.

The usage right management unit 34 receives the usage right sent fromthe content distribution device 1 in response to a content use request,and performs corresponding processing on the content (decryption,reproduction based on the usage condition, or the like) according to thedetails of the received usage right. Such usage right is stored andmanaged in the usage right database 35.

The output unit 37, an example of which is a display device such as adisplay, outputs the content according to the processing performed bythe usage right management unit 34.

The security management/communication unit 36 performs: authenticationof the content distribution device 1; secure communications(communications for preventing tapping and tampering and forauthenticating the party at the other end) between the contentdistribution device 1 and the user terminal 3; and countermeasures forcommunication disconnection. Details about the structure of the securitymanagement/communication unit 36 and the communication protocol aregiven later.

Next, referring to FIG. 2, a description is given of a detailedstructure of the security management/communication unit 17 in thecontent distribution device 1. A unique key information storage unit 201stores the following that are in accordance with public keycryptography: a server public key certificate that includes a public keyKDs that is unique to the content distribution device 1; a private keyKEs that is unique to the content distribution device 1; and acertificate authority public key certificate. The server public keycertificate is a result of affixing a signature of the certificateauthority to the public key KDs of the content distribution device 1. Ageneral X.509 certificate format is used as a format of the public keycertificate. Details about the public key cryptography and the X.509format are given in ITU-T document X.509 “The Directory: Public-key andattribute certificate frameworks”.

A random number generation unit 202 generates a random number. Thegenerated random number is passed to a control unit 204.

A cipher processing unit 203 performs data encryption, data decryption,signature generation, signature verification, the generation ofparameters for session key generation, and the generation of a sessionkey. Advanced Encryption Standard (AES) is used as an algorithm for dataencryption and decryption, and Elliptic Curve Digital SignatureAlgorithm (EC-DSA) is used as an algorithm for signature generation andsignature verification. Details about AES are provided in NationalInstitute Standard and Technology (NIST), FIPS Publication 197, anddetails about EC-DSA are provided in IEEE 1363 Standard.

When encrypting and decrypting data, the cipher processing unit 203outputs respective data obtained by performing encryption and decryptionusing an AES key that has been inputted, with the AES key, a plaintextand encrypted data as inputs. When generating and verifying a signature,the cipher processing unit 203 outputs signed data and a verificationresult, with data to be signed and data to be signature-verified as wellas a private key and a public key as inputs. When generating a parameterfor session key generation, the cipher processing unit 203 outputs aDiffie-Hellman parameter, with a random number as an input. Whengenerating a session key, the cipher processing unit 203 outputs asession key, with the random number and the Diffie-Hellman parameter asinputs. Here, Elliptic Curve Diffie-Hellman (EC-DH) is used for sessionkey generation. Details about EC-DH algorithm is given in theabove-mentioned IEEE1363 Standard.

The control unit 204 checks authentication processing performed on theuser terminal 3, encryption/decryption and tampering of data that issent/received to and from the user terminal 3. Furthermore, the controlunit 204 performs communication disconnection countermeasure processingby assigning a 1-bit transaction identification bit to a transaction,and by storing, into a communication log database 206, such transactionidentification bit and communication step information. Here, atransaction refers to a process unit such as “obtainment of a usageright” and “returning of the usage right”.

A communication unit 205 communicates with the securitymanagement/communication unit 36 of the user thermal 3.

Next, referring to FIG. 3, a description is given of a detailedstructure of the security management/communication unit 36 in the userterminal 3. A unique key information storage unit 301 stores thefollowing that are in accordance with public key cryptography: aterminal public key certificate that includes a public key KDc that isunique to the user terminal 3; a private key KEc that is unique to theuser terminal 3; and a certificate authority public key certificate. Theterminal public key certificate is a result of affixing a signature ofthe certificate authority to the public key KDc of the user terminal 3.A general X.509 certificate format is used as a format of the public keycertificate, as in the case of the content distribution device 1.

A random number generation unit 302 generates a random number. Thegenerated random number is passed to a control unit 304.

A cipher processing unit 303 performs data encryption, data decryption,signature generation, signature verification, generation of parametersfor session key generation, and generation of a session key. Inputs andoutputs to and from the cipher processing unit 303 are the same as thoseof the cipher processing unit 203 of the content distribution device 1.

The control unit 304 checks authentication processing performed on thecontent distribution device 1, encryption/decryption and tampering ofdata that is sent/received to and from the content distribution device1. Furthermore, the control unit 304 performs communicationdisconnection countermeasure processing by storing, into a communicationlog database 306, the transaction identification bit and communicationstep information generated by the content distribution device 1.

A communication unit 305 communicates with the securitymanagement/communication unit 17 of the user thermal 3.

Next, referring to FIG. 4 to FIG. 12, a concrete description is given ofa content distribution method to be performed in the contentdistribution system according to an embodiment of the present invention.

FIG. 4 is a flowchart that describes processing related to the purchaseof a content to be performed in the content distribution systemaccording to an embodiment of the present invention. FIG. 5 is a diagramthat schematically shows an example of content-related informationstored in the content right database 19. FIG. 6 is a diagram thatschematically shows an example of user information stored in the userdatabase 18. FIG. 7 is a diagram that schematically shows an example ofinformation about rights owned by users stored in the user-owned rightdatabase 20. FIG. 8 is a diagram that schematically shows an example ofcontent information stored in the content database 21. FIG. 9 is aflowchart that describes processing related to the use of a content tobe performed in the content distribution system according to anembodiment of the present invention. FIGS. 10A to 10C, FIG. 11, and FIG.12 are flowcharts that describe a secure communication and communicationdisconnection countermeasure processing to be performed in the contentdistribution system according to an embodiment of the present invention.

(1) Content Purchase Processing

Referring to FIG. 4, a description is given of processing to beperformed in the content distribution system when a user purchases acontent provided from the content distribution device 1.

In the user terminal 3, the user outputs, to the user instructionprocessing unit 31, an instruction concerning the purchase of a content.The user instruction processing unit 31 issues, to the contentdistribution device 1, a content purchase request according to theinstruction via the security management/communication unit 36 (StepS41).

In the content distribution device 1, the content purchase processingunit 11 receives, via the security management/communication unit 17, thecontent purchase request issued by the user terminal 3. Upon receipt ofthe content purchase request, the content purchase processing unit 11obtains, from the content right database 19, information about allcontents stored therein, and sends it to the user terminal 3 via thesecurity management/communication unit 17 (Step 542).

Here, information such as one shown in FIG. 5 is stored in the contentright database 19, for example. In FIG. 5, Content name is the name ofeach content, and Content ID is a unique number to be assigned toidentify each content. Usage condition indicates a specific rule underwhich it is possible to use each content in a predetermined data formatused at ordinary times. One or more usage conditions and fees may be setto each content. The present example shows that a usage condition in theform of the number of reproductions is set to a content called Movie A,and that it becomes possible to view Movie A twice by paying 400 yen.

Note that in addition to the number of uses and use time describedabove, it is possible to use, as usage conditions, a variety of rulessuch as use period and whether or not it is possible to copy a contentonto a storage medium and to print a content to a document.

Referring to FIG. 4 again, in the user terminal 3, in the case where thecontent-related information (FIG. 5) sent from the content purchaseprocessing unit 11 is checked and the user has determined to purchaseone of the contents (Step S43, Yes), the user instruction processingunit 31 sends, to the content distribution device 1, the userinformation stored in the terminal information storage unit 32, togetherwith a content purchase determination notice (including informationabout the purchased content and a selected usage condition) via thesecurity management/communication unit 36 (Step S44).

In the content distribution device 1, the content purchase processingunit 11 receives, via the security management/communication unit 17, thecontent purchase determination notice and the user information sent fromthe user terminal 3. Then, the content purchase processing unit 11performs necessary charging processing as well as sending, to the userregistration unit 12, the information about the purchased content andthe user information (Step S45). Note that since charging processing isoutside the focus of the present invention, a description thereof is notgiven.

The user registration unit 12 transfers, to the user right registrationunit 13, the information about the purchased content and the userinformation sent from the content purchase processing unit 11, as wellas storing and registering the user information into the user database18 (Step S47). In the case where information that is the same as theuser information sent from the content purchase processing unit 11 isalready registered in the user database 18, the above describedregistration is not carried out (Step S46, Yes).

Information such as one shown in FIG. 6 is stored in the user database18, for example. In FIG. 6, User ID is a unique number that is assignedto identify a user. User name is the name of a user. Terminal ID is aunique number that is assigned to identify a terminal and that is usedin such cases as where one user owns plural terminals. Telephone numberis used to identify a user. An example shown in FIG. 6 shows thatinformation indicating that “a user named “Ichiro” with the user ID“0001” uses a terminal with the ID number “1234567” is registered asuser information.

The user right registration unit 13 stores and registers, into theuser-owned right database 20, a right to use the content to be owned bythe user through purchase, based on the information about the purchasedcontent and the user information provided from the user registrationunit 12 (Step S48).

Information such as one shown in FIG. 7 is stored in the user-ownedright database 20, for example. In FIG. 7, User ID is informationregistered in the user database 18. Content ID and Usage condition areinformation registered in the content right database 19.

Through the above processing, the purchase of the content and theregistration of the user-owned right that accompanies such purchasecomplete.

(2) Content Use Processing

Next, referring to FIG. 9, a description is given of processing to beperformed in the content distribution system when the user uses thecontent s/he has purchased after the user-owned right is registered intothe user-owned right database 20 through the above-described processing.

In the user terminal 3, the user outputs, to the user instructionprocessing unit 31, an instruction concerning the use of the content.When this is done, the user givens an instruction as to how s/he intendsto use the content. For example, the user gives an instructionindicating the number of times s/he wishes to use the content in thecase where the usage condition of the purchased content is the number oftimes, and indicating minutes for which s/he wishes to use the contentin the case where the usage condition of the purchased content is alength of time. The user instruction processing unit 31 sends, to thecontent distribution device 1, a content use request according to suchinstruction via the security management/communication unit 36 (StepS91). Note that the content use request is not necessarily generatedaccording to a user instruction, and thus there may be the case where itis automatically generated inside the user terminal 3. For example, inthe case where a usage condition of a content supported by the terminal3 is fixed, it is possible to create a content use request inside theuser terminal 3 without requiring the user to give an instruction. Morespecifically, in the case where the user terminal 3 is a terminal thatis capable of obtaining and processing a usage right equivalent only tosingle-time use for each content use due to its limited storagecapacity, the user instruction processing unit 31 automatically createsa content use request in accordance with such terminal, and issues it tothe content distribution device 1. Such content use request includes thedetails of the above instruction, the user ID, the terminal ID, and thecontent ID.

In the content distribution device 1, the user right generation unit 14receives the content use request sent from the user terminal 3 via thesecurity management/communication unit 17. Upon receipt of the contentuse request, the user right generation unit 14 checks whether or notinformation corresponding to such request is registered, by reference tothe user database 18 and the user-owned right database 20 (Step S92).More specifically, the user right generation unit 14 first checkswhether or not the user ID and the terminal ID included in the contentuse request is registered in the user database 18. When judging that itis registered, the user right generation unit 14 then checks whether ornot the content ID included in the content use request and the usagecondition for the user ID according to the request are registered in theuser-owned right database 20.

When judging that information corresponding to the content use requestis registered, as a result of the check performed in the above Step S92(Step S93, Yes), the user right generation unit 14 generates a usageright according to the content usage request, and sends it to the userterminal 3 via the security management/communication unit 17 (Step S94).Furthermore, the user right generation unit 14 notifies the contentmanagement unit 16 of the content ID included in the content userequest. The content management unit 16 extracts the contentcorresponding to the content ID from the content database 21, and sendsit to the user terminal 3 via the security management/communication unit17 (Step S95).

Meanwhile, when judging that information corresponding to the contentuse request is not registered, as a result of the check performed in theabove Step S92 (Step S93, No), the user right generation unit 14notifies the user terminal 3, via the security management/communicationunit 17, that the content use request is rejected (Step S97).

Here, a usage condition is generated in the above Step S94 in the manneras described below. It is assumed that the registration details storedin the user-owned right database 20 becomes as shown in FIG. 7 as aresult of the user with the user ID “0001” purchasing a content inadvance.

Also assume the case where such user has sent a content use requestindicating that such user wishes to use the content with the content ID“112233” for one time. In this case, since the usage conditionregistered in the user-owned right database 20 is two times, the userright generation unit 14 generates a usage right that includesinformation for providing the number of reproductions=1 as requested andthat includes the decryption key of the content. Furthermore, at thesame time of generating such usage right, the user right generation unit14 updates the registration details by decrementing by one the number oftimes indicated by the usage condition registered in the user-ownedright database 20 (decremented from 2 to 1 in an example shown in FIG.7). However, the user right generation unit 14 does not update theregistration details in the case where a restart transaction isinstructed by the security management/communication unit 17 incommunication disconnection countermeasure processing. Details aboutcommunication disconnection countermeasure processing are given later.

Note that the user right generation unit 14 may previously store thegenerated user right on the assumption that a restart transaction is tobe issued by the communication disconnection countermeasure processing.This saves the trouble of generating a user right again when a restarttransaction is issued.

Note that in the case where there becomes no usage conditions that wereprovided through the purchase of the content, as a result of updatingthe information registered in the user-owned right database 20 everytime a user right is issued to the user terminal 3, such user-ownedright registered in the user-owned right database 20 may be eitherdeleted or remain there. In the case where the user-owned right remainsthere, it becomes easier to handle such cases as where the same user haspurchased the same content again and where a user returns a usage rights/he has obtained without using it.

Referring to FIG. 9 again, in the user terminal 3, the encrypted contentsent from the content distribution device 1 is stored into the contentstorage unit 33, and the usage right is inputted to the usage rightmanagement unit 34. The usage right management unit 34 decrypts thecontent using the decryption key included in the obtained usage right,and performs, through the output unit 37, the reproduction or the likeof the decrypted content according to the usage condition (Step S96).Note that the usage right that has been obtained is stored into theusage right database 35 to be used for managing the number of contentreproductions, total use time, and the like.

Through the above processing, it is possible to distribute a contentcorresponding to a requested usage condition.

(3) Secure Communication/Communication Disconnection Processing

First, referring to FIG. 10A, a description is given of an overview ofauthentication processing, processing for preventing usage right tappingand tampering, and communication disconnection countermeasure processingto be performed by the security management/communication units 17 and 18in the case where a content use request (Step S91 in FIG. 9) andtransmission of the usage right and content (Steps S94 and S95 in FIG.9) are carried out for plural times in the above-described content useprocessing.

All communications performed between the user terminal 3 and the contentdistribution device 1 are each made up of a request message started fromthe user terminal 3 and a response message returned from the contentdistribution device 1 in response to the request message. A pair of arequest and a response is refereed to as a phase, and securecommunication/communication disconnection processing is made up of fourtypes of phases as shown in FIG. 10.

An initial phase P1 is a phase for mutual authentication to be carriedout only once at the beginning after a session is established betweenthe user terminal 3 and the content distribution device 1. A descriptionis given of such initial phase P1 in the respective cases where thepreceding transaction of the initial phase P1 has ended normally andwhere it has ended abnormally due to a communication disconnection orthe like.

In the initial phase P1, in the case where the preceding transaction hasended normally, the user terminal 3 sends, to the content distributiondevice 1, authentication information A used by the content distributiondevice 1 to authenticate the user terminal 3 as a first request message.After verifying the authentication information A, the contentdistribution device 1 sends authentication information B used by theuser terminal 3 to authenticate the content distribution device 1. Whenthis is done, the content distribution device 1 sends, to the userterminal 3, the initial value (e.g., 0) of a transaction identificationbit T together with the authentication information B. After the userterminal 3 verifies the authentication information B, authenticationinformation C for finalizing the mutual authentication is not to be sentindividually but together with a request message for the following firstcommand communication phase 2. Meanwhile, in the case where thepreceding transaction has ended abnormally due to a communicationdisconnection or the like, the following points are different from theabove-described processing to be performed in the case where thepreceding transaction has ended normally: the value of the transactionidentification bit T sent from the content distribution device 1; andthat a transaction is to be restarted. In other words, the contentdistribution device 1 sends the value of the transaction identificationbit used in the transaction that has not ended normally as it is(without inverting it). Furthermore, the content distribution device 1regards the next request message as a request for a restart transactionto be carried out for the preceding transaction that has abnormallyended.

The first command communication phase P2 is a phase that is carried outonly once following the initial phase P1. The first transaction isprocessed in the first command communication phase P2. In this firstcommand communication phase P2, the user terminal 3 sends theauthentication information C and the transaction identification bit Ttogether with a request message. The value of the transactionidentification bit T to be sent here is (i) the value that is obtainedby inverting the transaction identification bit sent from the contentdistribution device 1, in the case where the preceding transactionprocess has completed normally, and (ii) the value that was used in thepreceding (suspended) transaction, in the case where the precedingtransaction process has not completed normally. In the case where thetransaction identification bit is inverted, the content distributiondevice 1 sends, to the user terminal 3, a response message correspondingto the request message, judging that a new transaction has started.Meanwhile, in the case where the transaction identification bit is notinverted, the content distribution device 1 sends, to the user terminal3, the same response message as that of the preceding transaction,judging that it is a restart transaction. The user terminal 3 which hasreceived the response message normally transitions to a commit phase P4by sending a commit message, in the case of not performing transactionprocesses successively. Meanwhile, the user terminal 3 which hasreceived the response message normally sends a request message for thefollowing command communication phase P3 a and the transactionidentification bit T without sending a commit message, in the case ofperforming transaction processes successively.

The command communication phase (P3 a and the like) is a phase thattakes place in the case where two or more transactions are processed inthe same session. In other words, the command communication phase P3 ais used in the case where a content use request and transmission of thecontent right and content are carried out for plural times. The commandcommunication phase P3 does not take place in the case where a contentuse request and transmission of the content right and content arecarried out only once. The command communication phase P3 is repeated bythe number of times equivalent to the number of transactions that followthe first transaction. In this command communication phase P3 a, thetransaction identification bit T is sent, instead of a commit message,together with a request message for the following command communicationphase (P3 b), without sending any commit messages.

Commit phase is a phase in which the content distribution device 1finalizes the completion of the transaction processes after all of suchtransaction processes end.

FIG. 10B is a diagram that illustrates the transition of the transactionidentification bit T in the case where plural transaction processes areperformed between the content distribution device 1 and the userterminal 3 without any communication disconnections in the fourcommunication phases shown in FIG. 10A.

The initial value (e.g., T=0) of the transaction identification bit T issent from the content distribution device 1 to the user terminal 3together with a response for the initial phase P1. Each of the contentdistribution device 1 and the user terminal 3 holds the initial value.This transaction identification bit T is inverted in the user terminal 3when the transaction process completes.

The user terminal 3 inverts the transaction identification bit T (T=1)upon receipt of the transaction identification bit T and theauthentication information C as a response for the initial phase P1.This inversion indicates that there is no abnormal transaction inparticular.

In the following first command communication phase P2, when receiving aresponse normally, the user terminal 3 inverts the transactionidentification bit T (T=0), judging that the transaction process hascompleted. In the following first command communication phase P3 a, whenreceiving a response normally, the user terminal 3 inverts thetransaction identification bit T (T=1), judging that the transactionprocess has completed. As described above, the user terminal 3 invertsthe transaction identification bit T in the case of normally receiving aresponse.

Since the inverted transaction identification bit T is sent togetherwith a request message for the following command communication phase,this sending serves as a notification to the content distribution device1 that a transaction process in the user terminal 3 has completed.

In the first command communication phase P2, the content distributiondevice 1 compares the initial value T (=0) which it holds and thetransaction identification bit T (=1) which it has received togetherwith the request message. When they do not match (when the receivedtransaction identification bit is inverted), the content distributiondevice 1 judges that the transaction process of the user terminal 3 inthe preceding suspended transaction has been completed, and then holdsthe received transaction identification bit T (1). Accordingly, thetransaction identification bit T held inside the content distributiondevice 1 is to be updated as well.

Similarly, in the command communication phase P3 a, the contentdistribution device 1 compares the initial value T (=1) which it holdsand the transaction identification bit T (=0) which it has receivedtogether with the request message. When they do not match (when thereceived transaction identification bit is inverted), the contentdistribution device 1 judges that the transaction process of the userterminal 3 in the first command communication phase P2 has beencompleted, and then holds the received transaction identification bit T(=0). Accordingly, the transaction identification bit T held inside thecontent distribution device 1 is to be updated as well. The sameprocessing is to be performed also in the case where successive commandcommunication phases follow.

After the completion of the last command communication phase, a commitmessage is sent from the user terminal 3 to the content distributiondevice 1. This marks the start of a commit phase P4. The contentdistribution device 1 deletes the transaction identification bit T whichit holds upon receipt of the commit message. The user terminal 3 deletesthe transaction identification bit T upon receipt of a response messageto the commit message. As described above, successive transactionprocesses are performed in a single session.

FIG. 10C is a diagram that illustrates the transition of the transactionidentification bit T in the case where plural transaction processes arenot performed normally between the content distribution device 1 and theuser terminal 3. This drawing shows the case where the user terminal 3has failed to receive the response message sent by the contentdistribution device 1 in the first command communication phase P2 due toa communication disconnection or the like.

In the case of failing to receive the response message normally, theuser terminal 3 restarts the communication from the initial phase again,in order to restart the suspended transaction.

At the starting point of the initial phase P11 shown in this drawing,the transaction identification bit T of each of the content distributiondevice 1 and the user terminal 3 equals to 1. In the initial phase P11,since the transaction identification bit T (=1) is stored inside thecontent distribution device 1 which has received the authenticationinformation A, it sends such transaction identification bit T (=1) andthe authentication information B to the user terminal 3. The userterminal 3 which receives them judges that the preceding request messagewhich it sent in the suspended transaction has been delivered to thecontent distribution device 1 but a response message to such requestmessage fails to have been delivered to the user terminal 3, because thetransaction identification bit T (=1) which it has received and thetransaction identification bit T (=1) which it holds match. In thiscase, the content distribution device 1 also judges that the transactionis in a state of suspension since the previously sent request messagehas been delivered to it. Furthermore, the user terminal 3 stores thetransaction identification bit which it has received without invertingit since the preceding transaction is being suspended.

In the following first command communication phase P12, the userterminal 3 sends again a request message with the same contents as thatof the previously sent request message, together with the transactionidentification bit T (=1). The content distribution device 1 which hasreceived it judges that the current transaction is a restart transactionof the suspended transaction, because the transaction identification bitT (=1) which it has received and the transaction identification bit T(=1) which it internally holds match. In this case, since thetransaction has not completed yet, the content distribution device 1does not invert the transaction identification bit which it internallyholds. Furthermore, the content distribution device 1 is to send again aresponse message to the request message.

The subsequent command communication phases are the same as those shownin FIG. 10B.

FIG. 10D is a diagram that illustrates the transition of the transactionidentification bit in the case where a transaction process is notperformed normally between the content distribution device 1 and theuser terminal 3. Unlike FIG. 10C, this drawing shows the case where thecontent distribution device 1 has failed to normally receive a requestmessage that precedes a response message in the first commandcommunication phase P2.

In the case of failing to receive a response message normally, the userterminal 3 restarts the communication again from the initial phase inorder to restart the transaction that is suspended.

At the starting point of the initial phase P12 shown in this drawing,the transaction identification bits T of the content distribution device1 and the user terminal 3 equal to 0 and 1, respectively. In the initialphase P12, since the transaction identification bit T (=0) is storedinside the content distribution device 1 which has received theauthentication information A, it sends such transaction identificationbit T (=0) and the authentication information B to the user terminal 3.The user terminal 3 which has received them judges that the precedingrequest message which it sent in the suspended transaction fails to havebeen delivered to the content distribution device 1, because thetransaction identification bit T (=0) which it has received and thetransaction identification bit T (=1) which it holds does not match. Inthis case, the content distribution device 1 does not judge that thetransaction is in a state of suspension since the previously sentrequest message fails to have been delivered to it. In contrast, theuser terminal 3 can judge that the transaction is suspended because ofthe request message having been undelivered. Furthermore, the userterminal 3 stores the transaction identification bit without invertingit since the preceding transaction is being suspended.

In the following first command communication phase P12, the userterminal 3 may send again a request message with the same contents asthat of the previously sent request message, together with thetransaction identification bit T (=1), or may send a new requestmessage. This is because the user terminal 3 is of the judgment that thetransaction is suspended because of the request message having beenundelivered. That is to say, this is because the content distributiondevice 1 will handle any request message as a new transaction. When theuser terminal 3 sends a request message again or a new message, thecontent distribution device 1 judges that the current transaction is anew transaction, because the transaction identification bit T (=1) whichit has received and the transaction identification bit T (=0) which itholds does not match, and stores the received transaction identificationbit T (=1) (this is, T held by the content distribution device 1 isinverted). Furthermore, the content distribution device 1 sends aresponse message according to the request message.

The subsequent communication phase are the same as those shown in FIG.10B.

Next, referring to FIG. 11 to FIG. 15, a description is given ofprocessing to be performed in each phase when a content use request(Step S91 in FIG. 9) and transmission of the content right and content(Step S94 and S95 in FIG. 9) are carried out for plural times.

FIG. 11 describes processing to be performed by the user terminal 3 andthe content distribution device 1 in the initial phase in the contentuse processing. FIG. 12 describes processing to be performed by the userterminal 3 after the initial phase, before the start of a first commandcommunication phase. FIG. 13 describes processing to be performed in thefirst command communication phase. FIG. 14 describes processing to beperformed in a command communication phase. FIG. 15 describes processingto be performed in a commit phase.

First, referring to FIG. 11, a description is given of processing to beperformed by the user terminal 3 and the content distribution device 1in the initial phase. The control unit 304 included in the securitymanagement/communication unit 36 of the user terminal 3 sends a randomnumber Rc generated by the random number generation unit 302 and theterminal public key certificate stored in the unique information storageunit 301 to the content distribution device 1 via the communication unit305, in the case where it is instructed by the user instructionprocessing unit 31 to send a content use request (Step S1101).

When receiving the random number Rc and the terminal public keycertificate from the user terminal 3 via the communication unit 205, thecontrol unit 204 included in the security management/communication unit17 of the content distribution device 1 first verifies the signature ofsuch terminal public key certificate by providing, to the cipherprocessing unit 203, the certificate authority public key certificatestored in the unique information storage unit 201 and the terminalpublic key certificate (Step S1102).

In the case where the verification has failed as a result of thesignature verification in Step S1102 (Step S1103, No), the control unit204 notifies the user terminal 3, via the communication unit 205, thatthe request is rejected (Step S1104).

Meanwhile, in the case where the verification has succeeded as a resultof the signature verification in Step S1102 (Step S1103, Yes), thecontrol unit 204 causes the random number generation unit 202 togenerate random numbers Rs and Rs2 and causes the cipher processing unit203 to generate a Diffie-Hellman parameter, using the random number Rs2as an input (Step S1105).

Furthermore, the control unit 204 searches the communication logdatabase 206 to check whether or not the transaction identification bitis stored. When the result of the search is that the transactionidentification bit is not stored (i.e., it is deleted in the precedingcommit phase, and the transaction ended normally), the control unit 204sets the transaction identification bit T to the initial value 0,whereas in the other case, it sets the transaction identification bit Tto the value of the transaction identification bit that is stored. Afterthis, the control unit 204 causes the cipher processing unit 203 togenerate a signature (Equation 2) for data (Equation 1) that resultsfrom concatenating the random number Rc received from the user terminal3, the transaction identification bit T, and DHs generated in Step S1105(Step S1106). Here, the transaction identification bit T is a bit thatis associated with a content request transaction to be performed in thefirst command communication phase that follows the present initialphase. In the case where a communication disconnection occursafterwards, the suspended transaction is restarted using thistransaction identification bit T.Rc∥T∥DHs  (Equation 1)S(s, Rc∥T∥DHs)  (Equation 2)

The control unit 204 sends the random number Rs and Diffie-Hellmanparameter DHs generated in Step S1105, the transaction identificationbit T, the server public key certificate stored in the unique keyinformation storage unit 201, and the signature (Equation 2) generatedin Step S1106, to the user terminal 3 via the communication unit 205(Step S1107).

Next, referring to FIG. 12, a description is given of processing to beperformed by the user terminal 3 after the initial phase, before thestart of a first command communication phase.

When receiving the random number Rs, the transaction identification bitT, the Diffie-Hellman parameter DHs, the server public key certificate,and the signature data from the content distribution device 1 via thecommunication unit 305, the control unit 304 included in the securitymanagement/communication unit 36 of the user terminal 3 first verifiesthe signature of such server public key certificate by providing, to thecipher processing unit 303, the certificate authority public keycertificate stored in the unique information storage unit 301 and theserver public key certificate (Step S1201).

In the case where the verification has failed as a result of thesignature verification in Step S1201 (Step S1202, No), the control unit304 notifies the user instruction processing unit 31 that the contentuse request is rejected (Step S1203).

Meanwhile, in the case where the verification has succeeded as a resultof the signature verification in Step S1201 (Step S1202, Yes), thecontrol unit 304 generates data (Equation 3) that results fromconcatenating the random number Rc generated in Step S1101 and thetransaction identification bit T and DHs that are received from thecontent distribution device 1 in Step S1107, and input, to the cipherprocessing unit 303, such data (Equation 3), the signature data(Equation 2) and the server public key certificate that are receivedfrom the content distribution device 1 in Step S1107, so as to verifythe signature data (Equation 2) (Step S1204).Rc∥T∥DHs  (Equation 3)

In the case where the verification has failed as a result of thesignature verification in Step S1204 (Step S1205, No), the control unit304 notifies the instruction processing unit 31 that the content userequest is rejected (Step S1203).

Meanwhile, in the case where the verification has succeeded as a resultof the signature verification in Step S1204 (Step S1205, Yes), the userterminal 3 can know that it is surely communicating with the contentdistribution device 1 (verification of the party at the other end). Thecontrol unit 304 causes the random number generation unit 302 togenerate a random number Rc2 and causes the cipher processing unit 303to generate a Diffie-Hellman parameter DHc, using the generated randomnumber Rc2 as an input (Step S1206).

Furthermore, the control unit 304 causes the cipher processing unit 303to generate a session key KS from the DHs received from the contentdistribution device 1 in Step S1107 and the Rc2 generated in Step S1206(Step S1207).

After this, the control unit 304 stores, into the communication logdatabase 306, the transaction identification bit T received from thecontent distribution device 1 in Step S1107 (Step S1208). Accordingly, acontent use request transaction corresponding to the transactioncommunication bit T is started, and the fact that it is a state forwaiting for a response is stored into the database.

The control unit 304 causes the cipher processing unit 303 to generate asignature (Equation 5) for data (Equation 4) that results fromconcatenating the random number Rs received from the contentdistribution device 1 in Step S1107 and the DHc generated in Step S1206,to invert the transaction identification bit stored in Step S1108 usingthe session key KS generated in Step S1207, and to encrypt the invertedtransaction identification bit T and a content use request message M(Step S1209). The content use request message includes at least thecontent identifier of the content to be used. A sequence number Seq anda hash value h are added to the encrypted data (Equation 6). A hashvalue is assigned to the sequence number Seq and the content use requestmessage M. The sequence number is a serial number which is reset to 0when a session starts, i.e., when the initial phase starts, and which isincremented by 1 every time a message is sent and received.Rs∥DHc  (Equation 4)S(c, Rs∥DHc)  (Equation 5)E(KS, Seq∥T∥M∥h)  (Equation 6)

The control unit 304 sends the DHc generated in Step S1206, and thesignature (Equation 5) and the encrypted data (Equation 6) that aregenerated in Step S1209, to the content distribution device 1 via thecommunication unit 305 (Step S1210).

Next, referring to FIG. 13, a description is given of processing to beperformed in the first command communication phase.

When receiving the Diffie-Hellman parameter DHc, the signature data, andthe encrypted data from the user terminal 3 via the communication unit205, the control unit 204 included in the securitymanagement/communication unit 17 of the content distribution device 1generates data (Equation 7) that results from concatenating the randomnumber Rs generated in Step S1105 and the DHc received from the userterminal 3 in Step S1210, and inputs, to the cipher processing unit 203,such generated data (Equation 7), the signature data received from theuser terminal 3 in Step S1210, and the terminal public key certificate,so as to verify the signature data (Step S1301).Rs∥DHc  (Equation 7)

In the case where the verification has failed as a result of thesignature verification in Step S1301 (Step S1302, No), the control unit204 notifies the user terminal 3, via the communication unit 205, thatthe content use request is rejected (Step S1303).

Meanwhile, in the case where the verification has succeeded as a resultof the signature verification in Step S1301 (Step S1302, Yes), thecontent distribution device 1 can know that it is surely communicatingwith the user terminal 3 (verification of the party at the other end).The control unit 204 causes the cipher processing unit 203 to generate asession key KS from the DHc received from the user terminal 3 in StepS1210 and the Rs2 generated in Step S1105. After this, the control unit204 inputs, to the cipher processing unit 203, the encrypted datareceived in Step S1210 and the generated KS so as to decrypt theencrypted data and check the sequence number and the hash value (StepS1304).

Furthermore, the control unit 204 searches the communication logdatabase to obtain the transaction identification bit. When the resultof the search is that the transaction identification bit is not presentor its value does not match that of the transaction identification bit Treceived in Step S1210 (Step S1305, No), the content distribution device1 judges that the request message is for a new transaction, and thecontrol unit 204 stores, into the communication log database 206, thetransaction identification bit T received from the user terminal 3 inStep S1301 (Step S1306). Accordingly, the transaction identification bitT is to be inverted. Furthermore, the fact that the content use requesttransaction has completed up to this step, is stored into the database.

After this, the control unit 204 notifies the user right generation unit14 of the content use request received from the user terminal 3 in StepS1210, as a new transaction (Step S1307).

Meanwhile, when the transaction identification bit is already presentand its value match that of the transaction identification bit Treceived in Step S1210 (Step S1305, Yes), the control unit 204 judgesthat the transaction is suspended due to a communication disconnectionor the like, and notifies the user right generation unit 14 of thecontent use request received from the user terminal 3 in Step S1210, asa restart transaction (Step S1308).

The control unit 204 causes the cipher processing unit 203 to encryptthe sequence number, the usage right generated by the user rightgeneration unit 14, and their hash value, using the session key KSgenerated in Step S1304, and sends the resultant to the user terminal 3via the communication unit 205 (Step S1309). Here, since the usage rightto be set has been encrypted using the session key KS that is generableonly by the content distribution device 1 and the user terminal 3, it isimpossible for a third party to tap the usage right.

When receiving the encrypted data from the content distribution device 1via the communication unit 305, the control unit 304 included in thesecurity management/communication unit 36 of the user terminal 3 firstcauses the cipher processing unit 303 to decrypt the encrypted datausing the session key KS so as to restore the sequence number, the usageright, and the hash value. After this, the control unit 304 checks thesequence number and the hash value, and notifies the usage condition(s)to the user instruction processing unit 31. Furthermore, the controlunit 304 inverts the transaction identification bit stored in thecommunication log database 306 (Step S1310). This marks the completionof the transaction corresponding to the transaction identification bitT.

After this, the processing goes to Step S1401 when there is a subsequenttransaction, whereas it goes to Step S1501 in the other case.

Next, referring to FIG. 14, a description is given of processing to beperformed in a command communication phase.

The control unit 304 encrypts the transaction identification bit Tstored into the content log database 306 and the content use requestmessage M, using the session key KS generated in the initial phase (StepS1401). The content use request message includes at least the contentidentifier of the content to be used. A sequence number Seq and a hashvalue h are added to the encrypted data. A hash value is assigned to thesequence number Seq and the content use request message M.

The control unit 304 sends the encrypted data generated in Step S1401 tothe content distribution device 1 via the communication unit 305 (StepS1402).

When receiving the encrypted data from the user terminal 3 via thecommunication unit 205, the control unit 204 included in the securitymanagement/communication unit 17 of the content distribution device 1inputs, to the cipher processing unit 203, the encrypted data and the KSgenerated in the first command communication phase so as to decrypt theencrypted data and check the sequence number and the hash value (StepS1403).

Furthermore, the control unit 204 searches the communication logdatabase to check whether or not the transaction identification bit Treceived from the user terminal 3 in Step S1402 and the transactionidentification bit T stored into the communication log database match.When the result of the check is that they do not match (Step S1404, No),the control unit 204 changes the data stored in the communication logdatabase 206 to T received from the user terminal 3 in Step S1402 (StepS1405). Accordingly, the transaction identification bit T is inverted.Furthermore, the fact that the content use request transaction hascompleted up to this step, is stored into the database.

After this, the control unit 204 notifies the user right generation unit14 of the content use request received from the user terminal 3 in StepS1402, as a new transaction (Step S1406).

Meanwhile, when the transaction identification bit T and the transactionidentification bit to be stored into the communication log database 206match (Step S1404, Yes), the control unit 204 judges that thetransaction is suspended due to a communication disconnection or thelike, and notifies the user right generation unit 14 of the content userequest received from the user terminal 3 in Step S1402, as a restarttransaction (Step S1407).

The control unit 204 causes the cipher processing unit 203 to encryptthe sequence number, the usage right generated by the user rightgeneration unit 14, and their hash value, using the session key KSgenerated in the first command communication phase, and sends theresultant to the user terminal 3 via the communication unit 205 (StepS1408). Here, since the usage right to be set has been encrypted usingthe session key KS that is generable only by the content distributiondevice 1 and the user terminal 3, it is impossible for a third party totap the usage right.

When receiving the encrypted data from the content distribution device 1via the communication unit 305, the control unit 304 included in thesecurity management/communication unit 36 of the user terminal 3 firstcauses the cipher processing unit 303 to decrypt the encrypted datausing the session key KS so as to restore the sequence number, the usageright, and the hash value. After this, the control unit 304 checks thesequence number and the hash value, and notifies the usage condition(s)to the user instruction processing unit 31. Furthermore, the controlunit 304 inverts the transaction identification bit T stored in thecommunication log database 306 (Step S1409). This marks the completionof the transaction corresponding to the transaction identification bitT.

After this, the processing goes to Step S1401 when there is a subsequenttransaction, whereas it goes to Step S1501 in the other case.

Finally, referring to FIG. 15, a description is given of processing tobe performed in a commit phase.

The control unit 304 encrypts a commit message using the session key KSgenerated in the initial phase (Step S1501).

The control unit 304 sends the encrypted data generated in Step S1501 tothe content distribution device 1 via the communication unit 305 (StepS1502).

When receiving the encrypted data from the user terminal 3 via thecommunication unit 205, the control unit 204 included in the securitymanagement/communication unit 17 of the content distribution device 1inputs, to the cipher processing unit 203, the encrypted data and the KSgenerated in the first command communication phase so as to decrypt theencrypted data (Step S1503).

Furthermore, the control unit 204 deletes the transaction identificationbit stored in the communication log database 206 (Step S1504).

The control unit 204 causes the cipher processing unit 203 to encrypt anACK message using the session key KS generated in the first commandcommunication phase, and sends the resultant to the user terminal 3 viathe communication unit 205 (Step S1505).

When receiving the encrypted data from the content distribution device 1via the communication unit 305, the control unit 304 included in thesecurity management/communication unit 36 of the user terminal 3 firstcauses the cipher processing unit 303 to decrypt the encrypted datausing the session key KS so as to restore the ACK message, and notifiesthe user instruction processing unit 31 that the commit processing hascompleted. After this, the control unit 304 deletes the transactionidentification bit T stored in the communication log database 306 (StrepS1506).

Note that a transaction restart process to be performed after acommunication disconnection is started in response to a transactionrestart process request sent from the user instruction processing unit31, and is restarted as a first command communication phase, after aninitial phase is processed, using the transaction identification bit(the transaction identification bit stored in the communication logdatabase) T corresponding to the transaction that is suspended due to acommunication disconnection. The content use request message to be sentin this first command communication phase may be passed to the controlunit 304 again by the user instruction processing unit 31 or may bestored by the control unit 304 into the communication log database atthe time of storing the transaction identification bit thereto, so thatsuch stored message can be used.

Through the above processing, it is possible to perform processing forauthenticating the user terminal 3, processing for preventing usageright tapping and tampering, and communication disconnectioncountermeasure processing.

In the communication protocols presented in the present embodiment, thenumber of sendings and receivings required for processing “n”transactions is one sending and receiving in the initial phase, onesending and receiving in the first command communication phase, n minusone sending and receiving in the command communication phase, and onesending and receiving in the commit phase, which amounts to a total ofn+two times.

Note that the encryption algorithm, session key sharing algorithm, andcertificate format used in the present embodiment do not necessarilyhave to be those described above, as long as they have the equivalentfunctions. For example, TripleDES may be used as the data encryptionalgorithm. Furthermore, checksum values such as CRC may be used as ahash value added to the encrypted data. Moreover, common keycryptography may be used as the SAC protocol instead of public keycryptography.

In the present embodiment, although the terminal public key certificateis sent from the user terminal 3 in the initial phase (Step S1101 inFIG. 11), it may be sent in the first command communication phase (StepS1210 in FIG. 12). Accordingly, it becomes not necessary for the contentdistribution device 1 to hold therein the above data. In this case, theprocessing to verify the signature of the terminal public keycertificate (Step S1102 in FIG. 11) performed by the contentdistribution device 1 is performed at the beginning of the first commandcommunication phase (immediately before Step S1301 in FIG. 13).

Note that in Step S1107, the data sent from the content distributiondevice 1 to the user terminal 3 may include the random number Rcreceived from the user terminal 3. In other words, the data to be sentfrom the content distribution device 1 are the random number Rc, therandom number Rs, the transaction identification bit T, the parameterDHs, and the signature data. Accordingly, it becomes not necessary forthe user terminal 3 to hold therein the random number Rc. Similarly, thedata sent from the user terminal 3 to the content distribution device 1in Step S1210 may include the random number Rs received from the contentdistribution device 1. In other words, the data to be sent from thecontent distribution device 1 are the random number Rs, the parameterDHc, the signature data, and the encrypted data.

Although the present embodiment includes the processing performed by theuser terminal 3 to authenticate the content distribution device 1, thisauthentication processing may be deleted if it is not particularlyrequired.

In the present embodiment, although the judgment of whether thetransaction identification bits match or not is made in the commandcommunication phase, this judgment processing may be deleted if it isnot particularly required. In this case, a transaction to be processedin the command communication phase is always processed as a newtransaction.

In the present embodiment, although the transaction identification bitis sent from the content distribution device 1, this may be omitted. Inother words, the processing performed by the content distribution device1 in the initial phase and information about the transactionidentification bit included in a message sent in the initial phase areomitted.

In the present embodiment, although registration details is not to beupdated in the case where the generation of the user right in Step S1308and Step S1407 is instructed by the security management/communicationunit 17 as a restart transaction, it is also possible to evaluate thecontent use request again and to generate the user right again.Accordingly, it becomes possible to respond to changes that occurbetween when a new transaction is issued and when a restart transactionis issued. For example, while the generation and sending of a usageright was performed since it was before the use expiration date of thecontent at the time of issuing a new transaction, there would be thecase where it is beyond such use expiration date when a request is madeagain as a restart transaction. In such case, no generation and issuingof a usage right is performed for the restart transaction.

Furthermore, the present embodiment may include processing for cancelinga transaction that is in process due to a communication disconnection.In the case of performing cancellation processing, a cancellationmessage is sent from the user terminal 3 in a first commandcommunication phase to be performed after communication disconnection,in response to an instruction by the user instruction processing unit31, the cancellation message including the transaction identificationbit T corresponding to a transaction for which a response is not yetreceived (the transaction identification bit T stored in thecommunication log database 306). The content distribution device 1 whichhas received the cancellation message notifies the user right generationunit 14 that it has received the cancellation message, so as to cause itroll back the state of the transaction in process to the state beforethe processing begins. After this, the content distribution device 1sends an ACK message to the user terminal 3.

Suppose that two processes for processing a content use requestperformed between the content distribution device 1 and the userterminal 3 are Process A and Process B. In the case where acommunication needs to be disconnected after the completion of ProcessA, authentication is performed again and a new session key is createdagain at the start of Process B in normal cases. However, if responsetime in Process B is wished to be reduced, it is also possible topreviously store the session key of Process A both in the contentdistribution device 1 and the user terminal 3 to use it again, so thatauthentication processing in Process B can be excluded.

Note that in the present embodiment, the content distribution device 1may set a limit on the use of a session key. For example, the contentdistribution device 1 notifies the user terminal 3 that the reuse of thesession key is not possible in cases such as: where the number of reusesof the session key exceeds a prescribed upper limit; where a prescribedlength of time has elapsed after the session key is first created; wherea prescribed amount of communication data is exceeded after the sessionkey is first created; where a predetermined content or usage right isdistributed; and where a predetermined content or usage right isdistributed to a predetermined user terminal 3. The user terminal 3which has received a notice indicating that the reuse of the session keyis not possible, creates a session key again, i.e., it restarts thecommunication from the initial phase again.

The present embodiment describes a protocol between the contentdistribution device 1 and the user terminal 3, but it is also applicableto license exchange between user terminals. For example, it isapplicable to the transfer of a license between user terminals in ahouse. In this case, a group identifier indicating that they are userterminals in the same house is specified in advance or through thesetting performed after the purchase. In the case where the protocolpresented in the present embodiment are applied to the transfer of alicense between user terminals, a terminal that transfers the license isconsidered as the content distribution device 1, whereas a terminal thatreceives the license is considered as the user terminal 3. When thetransfer of a license is limited to the transfer within the same house,i.e., only to those with the same group identifier, the licensereceiving terminal sends the group identifier to the licensedistributing terminal to judge whether the license distributing terminalhas the same group identifier or not, and sends the license only whenthe group identifiers are the same. Any method may be used to send thegroup identifier as long as such method is capable of preventingtapping, tampering, and spoofing. For example, the group identifier maybe included in encrypted data to be sent in the first commandcommunication phase. Furthermore, it is also possible to send a hashvalue of the group identifier without sending the group identifieritself. It is also possible to further provide, after the initial phase,a phase for sending a group identifier hash so as to send a groupidentifier hash encrypted with the session key.

Note that the components included in the content distribution systempresented in the present embodiment may be implemented either ashardware or software.

As described above, according to the present invention, it is possibleto provide a system and devices with which it is possible to (1) achieveall the functions, that is, the prevention of license tapping andtampering, the authentication of the party at the other end, andcountermeasures for communication disconnection, (2) reduce the numberof times sendings and receivings are carried out between a server deviceand a terminal device in the case where plural transaction processes areperformed, and (3) realize a protocol that requires the server deviceand the terminal device to manage and hold a small amount of informationto achieve the above functions. Accordingly, it becomes possible toprovide a content distribution system that is capable of reducing thetime the user has to wait until such user receives a response aftermaking a request.

INDUSTRIAL APPLICABILITY

The present invention is appropriate for use as a digital contentdistribution system including: a server device that provides a terminaldevice with a license for using a content, based on transactionprocesses including the receiving of a request message, the sending of aresponse message, and the receiving of a commit message for finalizingthe completion of the transaction; and the terminal device that controlsthe use of the content based on the license obtained from the serverdevice. For example, the following are appropriate as the server device:a distribution server of a service provider that distributes a digitalcontent via the Internet; a broadcasting device that digitallybroadcasts a digital content via broadcasting; and so forth, and thefollowing are appropriate as the terminal device: a set-top box forreceiving digital broadcasting; a content reproduction device and arecording device such as a digital TV, a DVD recorder, a hard diskrecorder, and a personal computer; a compound device of these; and soforth.

1-30. (canceled)
 31. A terminal device that obtains, from a serverdevice, a license for using a content based on transaction processes andcontrols use of the content based on the license, each of thetransaction processes including sending of a request message, receivingof a response message, and sending of a commit message for finalizingcompletion of one transaction, said terminal device comprising: aholding unit operable to hold a 1-bit transaction identification bitindicating whether a current transaction process is in progress orcompleted; and a sending unit operable to send the transactionidentification bit instead of a commit message when sending a second orlater request message, without sending a commit message in eachtransaction process except for a last transaction process in successivetransaction processes.
 32. The terminal device according to claim 31,comprising: a response receiving unit operable to receive each responsemessage sent from the server device in the transaction processes; and anupdate unit operable to update the transaction identification bit heldby said holding unit according to each reception result of said responsereceiving unit.
 33. The terminal device according to claim 32, whereinsaid update unit is operable to set a same value as a value of atransaction identification bit held by the server device as an initialvalue of the transaction identification bit held by said holding unit,and to invert a value of the transaction identification bit held by saidholding unit when a response message is received by said responsereceiving unit.
 34. The terminal device according to claim 33, whereinthe initial value of the transaction identification bit is included in afirst response message sent from the server device in the transactionprocesses, and said update unit is operable to set the transactionidentification bit held by said holding unit to the initial value whensaid response receiving unit receives the first response message, and toinvert the value of the transaction identification bit held by saidholding unit when a response message is normally received by saidresponse receiving unit.
 35. The terminal device according to claim 33,wherein said sending unit includes: a request sending unit operable tosend the transaction identification bit instead of sending a commitmessage when sending the second or later request message in thetransaction processes; and a commit sending unit operable to send thecommit message only in the last transaction process in the transactionprocesses.
 36. The terminal device according to claim 35, wherein saidrequest sending unit is operable to send the transaction identificationbit inverted by said update unit, together with a request message for anext transaction process, in the case where a response message isnormally received by said response receiving unit.
 37. The terminaldevice according to claim 36, wherein said request sending unit isoperable to send again the transaction identification bit that is notinverted, together with a request message for the current transactionprocess, in the case where a response message is not normally receivedby said response receiving unit.
 38. The terminal device according toclaim 32, wherein said terminal device performs processing for mutualauthentication with the server device immediately before a firsttransaction process in the transaction processes, and further comprises:an authentication unit operable to: provide said sending unit with firstauthentication information as an authentication request, the firstauthentication information being used by the server device toauthenticate said terminal device; verify second authenticationinformation that is received by said response receiving unit as aresponse to the first authentication information, the secondauthentication information being used by said terminal device toauthenticate the server device; and provide said sending unit with afinalization message for finalizing the mutual authentication accordingto a result of the verification, wherein said sending unit is operableto send the finalization message together with a request message for thefirst transaction process.
 39. The terminal device according to claim38, wherein the transaction processes are performed on a session that issame as a session on which the mutual authentication has been performed.40. The terminal device according to claim 38, wherein said update unitis operable to set a same value as a value of a transactionidentification bit held by the server device as an initial value of thetransaction identification bit held by said holding unit, and to inverta value of the transaction identification bit held by said holding unitwhen a response message is received by said response receiving unit. 41.The terminal device according to claim 40, wherein said sending unitincludes: a request sending unit operable to send the transactionidentification bit instead of sending a commit message when sending thesecond or later request message in the transaction processes; and acommit sending unit operable to send the commit message only in the lasttransaction process in the transaction processes.
 42. The terminaldevice according to claim 41, wherein said request sending unit isoperable to send the transaction identification bit inverted by saidupdate unit, together with a request message for a next transactionprocess, in the case where a response message is normally received bysaid response receiving unit.
 43. The terminal device according to claim31, wherein said request sending unit is operable to send again thetransaction identification bit that is not inverted, together with arequest message for the current transaction process, in the case where aresponse message is not normally received by said response receivingunit.
 44. A server device that provides a terminal device with a licensefor using a content based on transaction processes, each includingreceiving of a request message, sending of a response message, andreceiving of a commit message for finalizing completion of onetransaction, said server device comprising: a receiving unit operable toreceive a transaction identification bit that is sent, instead of thecommit message, together with a second or later request message insuccessive transaction processes, the transaction identification bitbeing a 1-bit flag indicating whether a transaction process is inprogress or completed in the terminal device; and a judgment unitoperable to judge whether or not completion of one transaction should befinalized based on the received transaction identification bit.
 45. Theserver device according to claim 44, wherein a value of the transactionidentification bit is inverted every time a transaction is processed bythe terminal device, and said server device further comprises a holdingunit operable to hold a first flag that is a copy of the transactionidentification bit that is sent together with a preceding requestmessage in the transaction processes, wherein said judgment unit isoperable to judge that completion of a preceding transaction should befinalized in the case where the transaction identification bit in thecurrent transaction process and the first flag held by said holding unitdo not match, the transaction identification bit being received by saidreceiving unit.
 46. The server device according to claim 45, comprisinga response sending unit operable to send, to the terminal device, aninitial value of the first flag as an initial value of the transactionidentification bit, together with a first response message in thetransaction processes.
 47. The server device according to claim 45,wherein said receiving unit includes: a request receiving unit operableto receive the transaction identification bit together with the secondor later request message; and a commit receiving unit operable toreceive a commit message only in a last transaction process in thetransaction processes.
 48. The server device according to claim 47,wherein said response sending unit is operable to send a responsemessage for a next transaction process in the case where said judgmentunit judges that the completion of the preceding transaction should befinalized.
 49. The server device according to claim 48, wherein saidresponse sending unit is operable to send again the response message forthe preceding transaction process in the case where said judgment unitjudges that the completion of the preceding transaction should not befinalized.
 50. The server device according to claim 45, wherein saidserver device performs processing for mutual authentication with theterminal device immediately before a first transaction process in thetransaction processes, and further comprises: an authentication unitoperable to: verify first authentication information that is received bysaid receiving unit as an authentication request, the firstauthentication information being used by said server device toauthenticate the terminal device; and provide second authenticationinformation that is used by the terminal device to authenticate saidserver device in the case where the first authentication information isverified as valid, wherein said request receiving unit is operable toreceive a finalization message for finalizing the mutual authenticationtogether with the first request message.
 51. The server device accordingto claim 50, wherein the transaction processes are performed on asession that is same as a session on which the mutual authentication hasbeen performed.
 52. The server device according to claim 51, whereinsaid receiving unit includes: a request receiving unit operable toreceive the transaction identification bit together with the second orlater request message; and a commit receiving unit operable to receive acommit message only in a last transaction process in the transactionprocesses.
 53. The server device according to claim 52, wherein saidresponse sending unit is operable to send a response message for a nexttransaction process in the case where said judgment unit judges that thecompletion of the preceding transaction should be finalized.
 54. Theserver device according to claim 53, wherein said response sending unitis operable to send again the response message for the precedingtransaction process in the case where said judgment unit judges that thecompletion of the preceding transaction should not be finalized.
 55. Adigital content distribution system comprising a server device and aterminal device, said server device providing said terminal device witha license for using a content based on transaction processes, eachincluding receiving of a request message, sending of a response message,and receiving of a commit message for finalizing completion of atransaction, and said terminal device controlling use of the contentbased on the license obtained from said server device, wherein saidterminal device comprises: a holding unit operable to hold a 1-bittransaction identification bit indicating whether a current transactionprocess is in progress or completed; and a sending unit operable to sendthe transaction identification bit instead of a commit message whensending a second or later request message, without sending a commitmessage in each transaction process except for a last transactionprocess in successive transaction processes, and said server devicecomprises: a receiving unit operable to receive the transactionidentification bit that is sent together with the second or laterrequest message in the successive transaction processes; and a judgmentunit operable to judge whether or not completion of one transactionshould be finalized based on the received transaction identificationbit.
 56. A transaction processing method for use in a terminal devicethat obtains, from a server device, a license for using a content basedon transaction processes and controls use of the content based on thelicense, each of the transaction processes including sending of arequest message, receiving of a response message, and sending of acommit message for finalizing completion of one transaction, said methodcomprising: a control step of performing a control so that a 1-bittransaction identification bit is to be sent instead of a commit messagewhen a second or later request message is sent, without sending a commitmessage in each transaction process except for a last transactionprocess in successive transaction processes, the transactionidentification bit indicating whether a current transaction process isin progress or completed; and a sending step of sending a commit messagein the last transaction process.
 57. A transaction processing method foruse in a server device that provides a terminal device with a licensefor using a content based on transaction processes, each includingreceiving of a request message, sending of a response message, andreceiving of a commit message for finalizing completion of onetransaction, said method comprising: a step of receiving a transactionidentification bit that is sent, instead of the commit message, togetherwith a second or later request message in successive transactionprocesses, the transaction identification bit being a 1-bit flagindicating whether a transaction process is in progress or completed inthe terminal device; and a judgment step of judging whether or notcompletion of one transaction should be finalized based on the receivedtransaction identification bit.
 58. A transaction processing method foruse in a digital content distribution system comprising a server deviceand a terminal device, said server device providing the terminal devicewith a license for using a content based on transaction processes, eachincluding receiving of a request message, sending of a response message,and receiving of a commit message for finalizing completion of atransaction, and the terminal device controlling use of the contentbased on the license obtained from the server device, said methodcomprising: a control step, executed by the terminal device, ofperforming a control so that a 1-bit transaction identification bit isto be sent instead of a commit message when a second or later requestmessage is sent, without sending a commit message in each transactionprocess except for a last transaction process in successive transactionprocesses, the transaction identification bit indicating whether acurrent transaction process is in progress or completed; a sending step,executed by the terminal device, of sending a commit message in the lasttransaction process; a receiving step, executed by the server device, ofreceiving the transaction identification bit that is sent, instead ofthe commit message, together with the second or later request message inthe successive transaction processes, the transaction identification bitbeing a 1-bit flag indicating whether a transaction process is inprogress or completed in the terminal device; and a judgment step,executed by the server device, of judging whether or not completion ofone transaction should be finalized based on the received transactionidentification bit.
 59. A program for causing transaction processes tobe executed in a terminal device that obtains, from a server device, alicense for using a content based on the transaction processes andcontrols use of the content based on the license, each of thetransaction processes including sending of a request message, receivingof a response message, and sending of a commit message for finalizingcompletion of one transaction, said program causing a computer in theterminal device to function as: a holding unit operable to hold a 1-bittransaction identification bit indicating whether a current transactionprocess is in progress or completed; and a sending unit operable to sendthe transaction identification bit instead of a commit message whensending a second or later request message, without sending a commitmessage in each transaction process except for a last transactionprocess in successive transaction processes.
 60. A program for causingtransaction processes to be executed in a server device that provides aterminal device with a license for using a content based on transactionprocesses, each including receiving of a request message, sending of aresponse message, and receiving of a commit message for finalizingcompletion of one transaction, said program causing a computer in theserver device to function as: a receiving unit operable to receive atransaction identification bit that is sent, instead of the commitmessage, together with a second or later request message in successivetransaction processes, the transaction identification bit being a 1-bitflag indicating whether a transaction process is in progress orcompleted in the terminal device; and a judgment unit operable to judgewhether or not completion of one transaction should be finalized basedon the received transaction identification bit.